Many devices today communicate with each other using the IP network. In order to provide mobility support to mobile devices, the Internet Engineering Task Force (IETF) has developed the “Mobility Support in IPv6” of the following non-patent document 1. In Mobile IP, each mobile node has a permanent home domain. When the mobile node is attached to its home network, it is assigned a primary global address known as a home-address (HoA). When the mobile node is away, i.e. attached to some other foreign networks, it is usually assigned a temporary global address known as a care-of-address (CoA). The idea of mobility support is such that the mobile node can be reached at the home-address even when it is attached to other foreign networks. This is done in the non-patent document 1 with an introduction of an entity at the home network known as a home agent (HA). Mobile nodes register their care-of-addresses with the home agents using messages known as Binding Updates (BU). This allows the home agent to create a binding between the home-address and care-of-address of the mobile node. The home agent is responsible to intercept messages that are addressed to the mobile node's home-address, and forward the packet to the mobile node's care-of-address using packet encapsulation (i.e. putting one packet as the payload of a new packet, also known as packet tunneling).
Although this enables mobility support, a problem known as sub-optimal or dog-leg routing arises. This is because when a mobile node communicates with a correspondent node (CN), packets sent between them must go through the home agent. For this reason, the non-patent document 1 specifies that the mobile node can send a BU to the correspondent node. Once the correspondent node knows of the binding between the home-address and care-of-address of the mobile node, packets traversing between them can be directly routed to and from the care-of-address of the mobile node (without going through the home agent). However, security is now a concern. BU sent from the mobile node to its home agent can be secured, because it is assumed that the mobile node and its home agent share a security association. Such an assumption becomes unrealistic for a mobile node and a correspondent node.
For this, the non-patent document 1 specified a procedure known as the Return Routability (RR) procedure, which allows the correspondent node to ascertain that the home-address and care-of-address specified in a BU are indeed collocated. In essence, the RR procedure requires the mobile node to obtain two securely generated tokens from the correspondent node prior to sending it a BU. To initiate the RR procedure, the mobile node first sends the correspondent node two different messages: a Home-Test-Init (HoTI) message, and a Care-of-Test-Init (CoTI) message. The HoTI is sent via the home agent with the mobile node's home-address as the packet source, and the CoTI is sent directly with the mobile node's care-of-address as the packet source. The correspondent node, upon receiving the HoTI, will reply with a Home-Test (HoT) message sent to the home-address of the mobile node that contains a security token, called the Home Keygen Token (HoK), cryptographically generated based on the home-address of the mobile node using a private key. Similarly, the correspondent node, upon receiving the CoTI, will reply with a Care-of-Test (CoT) message sent to the care-of-address of the mobile node that contains a security token, called the Care-of Keygen Token (CoK), cryptographically generated based on the care-of-address of the mobile node using a private key. Once the mobile node receives both the HoT and CoT messages, it can send the correspondent node a BU containing an Authenticator. This Authenticator is a cryptographically generated checksum of the BU using a key that is a concatenation of the HoK and CoK. In this way, when the correspondent node receives the BU, it can independently calculate the checksum and check that the checksum is identical to that carried in the Authenticator. This verifies that the care-of-address and the home-address specified in the BU are indeed collocated.
In the following patent document 1, it was argued that the original return routability procedure is susceptible to man-in-the-middle attack. Following this argument, the patent document 1 proposes a variation of the return routability procedure where the home agent sets up a key exchange with the correspondent node, and passes the key information to the mobile node.
With the ever-increasing proliferation of wireless devices, it is foreseeable that a new class of mobility technology will emerge: network mobility, where a whole network of nodes changes its point of attachment in entirety. Extending the concept of mobility support for individual hosts to mobility support for a network of nodes, the objective of a network in motion solution is to provide a mechanism where nodes in a mobile network can be reached by their primary global addresses, no matter where on the Internet the mobile network is attached to. There exist a few prior attempts to solve the network in motion problem based on Mobile IP. One proposed solution for network in motion is the Mobile Router Support described in the following patent document 2. Here the mobile router controlling a mobile network performs routing of packets to and from the mobile network using some routing protocols when it is in its home domain. When the mobile router and its mobile network move to a foreign domain, the mobile router registers its care-of-address with its home agent. A tunnel is then set up between the mobile router and the home agent. The routing protocol used when the mobile router is at its home domain is again performed over the tunnel. This means that every packet going to the mobile network will be intercepted by the home agent and forwarded to the mobile router through the tunnel. The mobile router then forwards the packet to a host in its mobile network. When a node in its mobile network wishes to send a packet out of the network, the mobile router intercepts the packet and forwards the packet to the home agent through the tunnel. The home agent then sends the packet out to the intended recipient. Another solution disclosed in the following patent document 3 is largely similar, except it specifically stated support for IPv6 only. In the following patent document 4, a method of using a multicast address as the care-of-address of the mobile router is disclosed. This allows the mobile router to be reached using the same care-of-address even after it has moved to a new access network. The IETF is also currently developing solutions for network mobility as disclosed in the following non-patent document 2, known as NEMO Basic Support. In NEMO Basic Support, which is an extension of Mobile IPv6, it is specified that the mobile router when sending BU to its home agent, will specify the network prefixes that the nodes in the mobile network are using. These are specified using special options known as Network Prefix Options to be inserted into the BU. These allow the home agent to build a prefix-based routing table so that the home agent will forward any packets sent to destinations with these prefixes to the care-of-address of the mobile router.
Even when a mobile network node uses route optimization technique as described in Mobile IPv6 to communicate with a correspondent node, it will still suffer from sub-optimal routing because of the tunneling between the mobile router and its home agent. This is illustrated in FIG. 1. Here, the mobile node MN 120 is attached behind a mobile router MR 110 to access the global internet 100. MN 120 is communicating with correspondent node CN 140. Home agent HA 130 is the home agent for MR 110, and home agent HA 135 is the home agent for MN 120. Even when MN 120 and CN 140 have completed the return routability test and are using route optimization, packets sent between them still must follow the path 150, 151 and 152. This is because MR 110 and HA 130 maintain a bi-directional tunnel 151.
One way of achieving true route optimization is to include the mobile router information (called upper-level router information, usually, but not limited to, the address of the upper-level router) in the BU message sent to the correspondent node, as described in the following non-patent document 3 and the following non-patent document 4. In the non-patent document 3, this is achieved by using a reverse routing header attached to the data packet to allow upper level routers to record their respective addresses. A recipient (such as correspondent node) can then send packet directly to the mobile node by specifying a routing header that reverses the order of addresses found in a reverse routing header. In the non-patent document 4, this is achieved by the mobile node using a special option called access router option to convey the address of the upper level router. This way, the recipient can sent packet to the mobile node via the upper level router by using a reverse routing header.
Non-patent Document 1: Johnson, D. B., Perkins, C. E., and Arkko, J., “Mobility Support in IPv6”, IETF RFC 3775, June 2004.
Non-patent Document 2: Devarapalli, V., et. al., “NEMO Basic Support Protocol”, IETF Internet Draft: draft-ietf-nemo-basic-02.txt, December 2003.
Non-patent Document 3: Thubert, P. et. al., “IPv6 Reverse Routing Header and its Application to Mobile Networks”, IETF Internet Draft: draft-thubert-nemo-reverse-routing-header-05.txt, June 2004.
Non-patent Document 4: Ng, C. W. et. al., “Securing Nested Tunnel Optimization with Access Router Option”, IETF Internet Draft: draft-ng-nemo-access-router-option-01.txt, July 2004.
Patent document 1: Lee, Yooung-Ji, “Return Routability Method for Secure Communication”, US Patent Application US20040179688A1, September 2004.
Patent document 2: Leung, K. K., “Mobile IP mobile router”, U.S. Pat. No. 6,636,498, October 2003.
Patent document 3: Markki, O. E., et. al., “Mobile Router Support for IPv6”, US Patent Application US20030117965A1, March 2002.
Patent document 4: Korus et. al., “Method and Apparatus for providing IP mobility for mobile network”, US Patent Application US20030095523A1, May 2003.
However, both the non-patent document 3 and the non-patent document 4 do not specify how the correspondent node can verify that the upper level router information (i.e. the reverse routing header or the access router option) is authentic. Absence of such verification method will expose the correspondent node to various security vulnerabilities. For instance, an attacker may specify a victim's address in the upper-level router information in a BU message sent to a correspondent node. Without a way to verify if the upper-level router information is correct, the correspondent node may unknowingly send packets destined for the attacker to the victim's address as an intermediate location, thus flooding the victim's network with unwanted packets.
The patent document 1 describes that the original return routability procedure is susceptible to man-in-the-middle attack and discloses a method where the home agent sets up a key exchange with the correspondent node, and passes the key information to the mobile node. This method, however, increases home agent complexity and processing load.